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Abstract 

We propose a new simple trace logic that can be used to specify local 
security properties, i.e. security properties that refer to a single participant 
of the protocol specification. Our technique allows a protocol designer 
to provide a formal specification of the desired security properties, and 
integrate it naturally into the design process of cryptographic protocols. 
Furthermore, the logic can be used for formal verification. We illustrate 
the utility of our technique by exposing new attacks on the well studied 
protocol TMN. 

Revision history: Nov 5 2004. Comments: fixed typos. 
Revision history: Nov 30 2004. Comments: added (variable) 
events Definition [5] , update bindings in execution, Definition l8l 
removed Implementation section. 



1 Introduction 



Cryptographic protocols are typically designed to meet security goals such as 
authentication and confidential key exchange. These goals, usually called secu- 
rity properties, can be correctly accomplished if some of the values exchanged 
during the protocol run satisfy, for instance, classical properties like authentic- 
ity, confidentiality, or freshness. 

Often, the specification of security properties is carried out by writing of 
"global" security properties. These security specifications do not depend from 

*We would like to thank Cabernet and the EYES Project (1ST- 2001-34734) for their 
support of this work. 
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any principal's point of view. Thus, to refer to a specific principal, global 
security properties are usually denned using extra protocol events |51ITT]. 

In this paper, on the other hand, we propose a logic that can be used to 
express local security properties, i.e. properties that refer to the specification 
of one agent, namely the agent which they belong to. As we show in the 
following sections, local security properties are expressive enough to assert the 
properties that are commonly desired for cryptographic protocols (e.g., freshness 
of a nonce.) 

The advantage of local properties is that they allow a designer to specify 
the security properties that should hold, according to each participant, at each 
protocol execution point. For instance, a property like freshness of a nonce 
can be specified as a formula that is connected directly to the corresponding 
participant who receives that nonce. Furthermore, since these formulae corre- 
spond to each principal, they depend only on information of that principal, as 
opposed to a global formula that can depend on the whole network state. Thus, 
a local formula can be bound to each principal and then be "plugged in" into 
any other network specification. This enables potential composability of the 
specifications. 

Consequently, using local properties, it is possible to integrate the specifica- 
tion of the (logical) security properties that a protocol has to meet within the 
(algorithmic) specification of the protocol itself. This yields an integrated tech- 
nique for protocol engineering that combines tightly the design and the analysis 
phase, resulting in a shorter design- verification feedback loop. 

We illustrate our approach by studying the TMN protocol ^H] for which we 
have found two new attacks. 

Plan of the paper. In Section we describe our security protocol model. 
Then, in Section [3| we introduce our trace logic language. In Section the 
TMN protocol is studied and some novel attacks upon it are presented. In 
Section [3] elaborates the related work and finally conclusions and future work 
are discussed in Section 

2 Protocol Model 

A protocol step is usually specified using the standard notation A — > B : M . 
Here, M is a message built from: 

• atomic terms, that is constants (written in lowercase) and variables (which 
are capitalized). Constants may be nonces (e.g. na) or agent identities 
(e.g. a). A special constant e denotes the intruder. 

• constructed terms, that is a finite application of operators encryption Mk, 
pairing My, M%, hashing h{M) and finally public key pk(M) over atomic 
terms. 

However, the A — > B : M notation is unsuitable for formal verification. In fact, 
in a protocol step, two different events take place: A sends message M, and B 
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receives message M' . In presence of an intruder, M might not be equal to M 1 . 
Moreover, not even the identities of the correspondent communication parties 
may be the same (i.e., A sends to B' and B receives from A'.) It is therefore 
convenient to take an approach that considers separately each agent's point of 
view; this is the idea of protocol roles. 

Definition 1 A protocol role is a pair (A, [MioBi, M n oB n ]), where A, Bi, B,, 
are variables, o £ {<,>} and Mi, M n are messages. □ 

Given a protocol role (A, [Mi o Bi, ...,M n o B n ]), A is called the identity of 
the role, while elements Mi oBi,i — l..n are the actions of the role: M t> B is a 
send action, while M < B is a receive action. 

Protocol roles in a security protocol often receive (self explanatory) names 
such as initiator, responder and server. For example, 

responder(A,B,Na) = (B, [pk(Na) < A]) (1) 

defines a responder role in which there is only one action, the receipt of Na from 
A. 

Notice that in QJ, the variables A, B, Na are still uninstantiated (we borrow 
this concept from logic programming: as long as no value is assigned to a vari- 
able, we call it uninstantiated, and instantiated otherwise.) In fact, a protocol 
role is parametric, thus representing a template. By appropriately (partially) in- 
stantiating a finite number of protocol roles, a system scenario can be obtained: 



Definition 2 A system scenario is a multiset of (partially) intantiated protocol 
roles. 

Typically, a system scenario determines how many sessions are present and 
which agents play which roles. For instance, the system scenario 

{responder ( A, b,N a), responder( C,d,Nc)} 

(where responder is the role defined above) defines a system scenario with two 
responders (notice that there are no corresponding initiators), one played by 
b and the other by d. Uninstantiated variables represent unknown values: for 
example, variable A in the first responder role represents the (unknown) com- 
municating party of b. 

2.1 Trace Semantics 

Executions of system scenarios are described using traces, which are in turn 
composed of events, i.e. single actions performed by an agent. 

Definition 3 An event is a pair {A : M o B) where A, B are agent's names, 
o G {<, >} and M is a message. □ 
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The event (A : M > B) should be read as "agent A sends message M with 
intended destination B" . On the other hand, {B : M < A) stands for "agent B 
receives message M apparently from A" . 

To analyze the protocol, we combine the system scenario with the usual 
Dolev-Yao intruder [Sj, who can perform the usual actions: intercept and learn 
any sent message, store the information contained in intercepted messages for 
later use, and introduce into the system new messages forged using information 
the intruder knows. The information obtained by the intruder is stored in a set 
of terms K called the intruder's knowledge 1 

Now we are ready to describe the execution of a system scenario, represented 
by the notion of a run. 

Definition 4 Let S be a system scenario, and K be the intruder's initial knowl- 
edge, consisting of constants representing agents identities and their public keys. 
Let tr be an initial empty trace. A run of S is a trace obtained by a reiterated 
sequence of the following steps: 

1. a non-empty role in S is chosen nondeterministically, and its first action 
p is removed from it. Let a be the identity of the chosen role. 

2. if p — tt> y, then: 

(a) t is added to the knowledge of the intruder, K := K U {t} 

(b) event e — {a : p) is added to tr, tr := tr ■ e 

3. if p — t <\y, then: 

(a) it is checked if the intruder e can generate t using the knowledge K 2 , 
if so, then event e = (a : p) is added to the trace: tr := tr ■ e. 

(b) If e cannot generate such a message, then the run stops. 

□ 

3 A Trace Logic 

In this section we introduce a trace logic language for defining local security 
properties. 

Definition 5 A trace logic formula is generated according to the following gram- 
mar: 



1 Because of the symbolic nature of the analyzer, in practice an event can contain variables, 
which stand for something the intruder can generate (see for details.) 

2 We adopt Millen and Shmatikov's constraint solving procedure 1131 for checking if the 
intruder can generate a term t using knowledge K. This procedure may involve instantiation 
of variables in t or K; for example, t may unify with a term in K, representing that t is already 
in K, i.e., is already known by the intruder (see 1131 for details.) 
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F ::= true | false | Fi A F 2 \ Fi V F 2 | Fi -> F 2 | Ve G tr : F 
| Be G ir : F |3t : F |-F |ei = e 2 | ei ^ e 2 

where e, e\ and e 2 are (variable) events. □ 

The conjunction of two formulae has the usual significance: Fl A Fi is in/e 
if both Fl an d F 2 are true; the disjunction operator V and implication — ► are 
analogous. On the other hand, the meaning of constructors Ve 6 tr : F and 
3e G tr : F is non-standard. Since a trace formula is going to be evaluated on 
a certain input trace, constructors V and 3 allow us to reason about the events 
in the input trace: Ve G tr : F asserts that every event e in the input trace 
satisfies formula F, while 3e G tr : F express that some event in the input 
trace satisfies formula F. Notice that tr is not a variable, it is just part of the 
operators name to emphasize that e ranges over the system trace. Even though 
this gives a "temporal" flavor to our logic, we anticipate that these constructors 
only operate on past events, recorded in the input trace (see later). Formula -F 
has the usual meaning of negation. Differently from the above operators, 3t : F 
quantifies t over all messages and agents space. Finally, predicates ei = e 2 and 
d if! e 2 allow us to compare events: the former asserts equality, and the latter 
subterm inclusion. 

While the choice of these constructors may seem rather ad hoc for our pur- 
poses, we believe this logic can in fact be quite expressive, and allow us to assert 
a fairly large set of interesting security properties, as will be shown later. 

Next, we define the precise meaning of a trace logic formula. 

Definition 6 Let T be the set of well-formed trace logic formulae, and TR be 
the set of traces, then the semantic function [•]• : T x TR — > {true, false} is 
defined as follows: 

[true] tr = true 

[false] tr = false 

[Fi A F 2 ] tr = true iff [Fi] tr = [F 2 ] tr = true 

[Fi V F 2 ] tr = true iff [Fi] tr = true or [F 2 ] tr = true 

[Fi -f F 2 ]tr = true iff [Fi] tr implies [F 2 ] tr 

[Ve G tr : F] tr =true iff, for each event x of tr , [F[ x /e]] tr — true 

[Be G : F] tr =true iff, for some event x oftr, [F[ x /e]] tr — true 

\3t : Fj tr =true iff, for some message or agent x, [F[ x /t]j tr = true 

[-F] tr = true iff {Fj tr = false 

[ei = e 2 ] tr = true iff event ei is equal to event e 2 

[ti r< 12] rr = true iff, if ti is a subterm of £ 2 

□ 

Here, F[x/y] is the result of substituting each occurrence of y with x in F. 

For the sake of notation's simplicity, we assume that all variables that are 
not explicitly quantified are existentially quantified (over the set of messages 
and agents). This simplifies the notation considerably. 

In the future, we plan to endow our logic with a proof system that allow 
us to relate proofs of formulae with the intended meaning given by [•]•. In 
the present work, we are more interested in exploring the expressive power of 
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security specifications; We plan to continue this work by addressing the issue of 
using our logic for automatic formal verification. 

3.1 Appending local security properties to protocol roles 

Now, we are ready to combine the definition of protocol roles and local security 
properties to obtain extended protocol roles and extended system scenarios. In- 
tuitively, the idea is to embed the logical security properties within the protocol 
specification. 

Definition 7 An extended protocol role is a triple (A, [Mi o B\ : F\, M n o 

B n : F n ]}> where {A, B\, B n } C Var, M±, M n are messages, o G {<, >} 
and F±, F n are trace logic formulae. □ 

Intuitively, adding a formula Fj after a protocol role action means that Fj 
must hold after the execution of the action. Notice that instantiation of an 
extended protocol role also affects the variables of an attached local security 
property. This formalizes the notion of a security property being 'local', that 
is a security specification that takes into account the principal's point of view. 
Also, Fi is going to be evaluated w.r.t. the system trace, which contains the 
events up to at that precise execution time. This, as we already mentioned, 
illustrates the "past flavour" nature of our formulae. 

Similarly, we can define an extended system scenario as a multiset of (par- 
tially instantiated) extended protocol roles. 

3.2 Verifying the local security properties 

To evaluate the local security properties, we extend the Definition |H1 to the 
extended system scenarios introduced in last section: 

Definition 8 Let S be an extended system scenario, and K be the intruder's 
initial knowledge, consisting of constants representing agents identities and their 
public keys. Let tr be an initial empty trace. A run of S is a trace obtained by 
a reiterated sequence of the following steps: 

1. a non-empty role in S is chosen nondeterministically, and its first action 
p is removed from it. Let a be the identity of the chosen role. 

2. if p = t> y : F , then: 

(a) if \F\tr holds, then update the resulting bindings (which appear from 
the existencially quantified variables) and continue. Otherwise, the 
run stops. 

(b) t is added to the knowledge of the intruder e, K := K U {t} 

(c) event e — (a : p) is added to tr, tr :— tr ■ e 

3. if p — t<y : F, then: 
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(a) it is checked if the intruder e can generate t using the knowledge 
K (see below), if so, then event e = (a : p) is added to the trace: 
tr := tr ■ e. 

(b) if \F\tr holds, then continue. Otherwise, the run stops. 

(c) If e cannot generate such a message, ore simply decides to finish the 
execution, then the run stops. 

□ 

For example, consider the role: 

responder(B, A, Na) = (B, [Na<A : F}) 

where F = Be : e = {A : Na > B). 

After the responder B receives the nonce Na, F checks that A had sent Na 
to B before. Now, consider the singleton scenario {responder (b, A, N a)}. In this 
scenario, there is only one honest responder role, played by b. Now, suppose 
this responder role receives, from the intruder e, a nonce ni as Na. Therefore, 
according to Definition |H1 we have trace tr = (e : ni>b). The next step involves 
evaluation of \F\tr to see if the local security property F holds: clearly, we can 
see that |3e : e — (A : Na\>b)J(e : ni>b) evaluates to true, assigning e to A and 
ni to Na. 



4 A Case Study: the TMN protocol 

We apply our technique to a well known case study, the TMN protocol ^UJ- This 
protocol has been thoroughly studied, see for example ^3EJ0I|- However, in 
this section we present some vulnerabilities that we believe no one has noticed 
before. 



4.1 Original Version 

The original version of TMN was proposed for achieving key distribution be- 
tween two users: 

Message 1. A -> S : A, S, B, {Ri} p k(s) 

Message 2. S^B : S,B,A 

Message 3. B -» S : B, S, A, {R 2 } pk(S ) 

Message 4. S -> A : S, A, B,v{R x , R 2 ) 

We denote Vernam encryption by v(ti,t2) 3 . Here, keys R± and i?2 are sent 
from A and B to S, respectively. After Message 4 is received, A can obtain i?2, 
thus making R 2 the shared key between A and B. 

3 We currently model Vernam encryption as normal symmetric encryption, and not as full 
exclusive xor. 
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4.1.1 TMN protocol roles. 



The first step in our design and verification technique is to obtain the protocol 
roles from the standard notation: 



• Initiator: (A, [A, S, B, {Ri} pk[s) > S : F 1 , S, A, B,v{R u R 2 ) < S : F 2 ]) 

• Responder: (B,[S,B,A< S : F 3 , B, S, A, {R 2 } pk{S ) > S : F 4 }) 

. Server: (S, [A, S, B, {Rt} pk ^<A : F 5 , S,B,A>B:F e , B,S,A,{R 2 } pk(s) < 
B:F 7 , S,A,B,v(R 1 ,R 2 )>A:F a \) 



This translation can be tedious and error-prone when protocols get large; 
however, we believe this step can be mostly automated (eg. by a tool assisting 
the user.) 

The original version of TMN suffers from several secrecy attacks over R 2 
above, as exposed for instance in Thus, we will concentrate on two modified 
versions of the protocol. 

4.2 First modification 

A replay attack against TMN was exposed by Simmons JS| • The attack exploits 
the fact that the messages to the server from A and B (Message 1 and Message 
3) can be replayed. To solve this defhciency, Tatebayashi and Matsuzaki intro- 
duce timestamps in messages 1 and 3 |10j : 



In this new protocol, after receiving Ta and Tg, the server can check for the 
timeliness of these timestamps. According to Tatebayashi and Matsuzaki, this 
new protocol version guarantess the freshness of R\ and R 2 . To check if this is 
true, we can specify the freshness requirements of R\ and R 2 as a local security 
properties of server S: 

Fresh^ — Ve G tr : last_event(e) V ~^(Ri ^ msg(e)) (for i = 1,2) 

Where primitive msg(-) projects the message of an event, defined as msg((x : 
m o y)) — m and predicate last-event{e) is a primitive that is true iff e is 
the last event of trace tr. The definition of this primitive is straightforward: 
\last-.event(e)\ tr = true iff tr = tr 1 ■ e. Fresh^ and Freshn 2 are expressing 
that R\ and R 2 , respectively, are fresh. 

The last step involves deciding where to put Fresh^ and Freshn 2 in the 
server role. This is easy: we make the decision that the formulae for checking 
the freshness of the received values should be placed as soon as the values are 
received. Thus, Fresh^ can be put as -F5, that is, after i?i is received. Similarly, 
we set FreshR 2 as F-j. 



Message 1 
Message 2 
Message 3 
Message 4 



.4 
S 
B 
S 



S 
B 
S 
A 



A, S, B , {Ta, Ri} p k(s) 
S,B,A 

B, S, A, { T B , R 2 } p k(s) 
S,A,B,v(Ri,R 2 ) 
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4.3 First novel attack 



After verification, we found a violation of formula F 5 (that is, freshness of Ri). 
The attack is reported in Tabled 



Table 1: R\ freshness attack. e(s) is e masquerading as s. a and (3 denote two 
different runs. 



Message a.l. 


a — > 


£ ( S ) 


: a,s,6, {i a , ri} P fc( s ) 


Message a.l'. 


e(a) 


— * s 


: a, s, 6, J"e}pfe(s) 


Message a. 2. 


s — > 


b : 


s, 6, a 


Message a. 3. 


b -> 


e(s) 


: b,s,a,{t b ,r 2 } p k{ s ) 


Message a. 3'. 


e(b) 


— > s 


: 6, s, a, n} P fe( s ) 


Message a. 4. 


s — > 


e(a) 


: s,a,b,v(r e , r\) 


Message (3.1. 


e(a) 


— > s 


: a,s,b,{te2,ri} pk ( s ) 



In this attack, the intruder starts replacing messages a.l with a.l' and a. 3 
with a. 3', and finally obtains r-y from message a. 4. But, when it wants to use it 
in a new run /3, even if the intruder uses a new (not expired) timestamp t e i , the 
formula F$ does not hold since r\ is not fresh (note that s is the same server, 
involved in both runs a and (3). It is important to notice why this attack repre- 
sents a vulnerability of the protocol. According to Tatebayashi and Matsuzaki, 
the server has to check for the validity of the timestamps in order to guarantee 
the freshness of R\ and R 2 ; as we can see in this attack, this is not sufficient. 
To the best of our knowledge, this vulnerability was never exposed before. 



4.4 Second modification 

A modification to assure authentication of the initiator and responder to the 
server consists in using Sa and Sb, shared secrets between S and A and B 
respectively, in the following manner: 

Message 1. A -> S : A,S,B,{T A ,S A ,Ri} P k(s) 

Message 2. S -> B : S,B,A 

Message 3. B^S : B,S,A,{T B ,S B ,R 2 } pk{S ) 

Message 4. S —> A : S,A,B,v(R- L ,R 2 ) 

After receiving messages 1 and 3, the server can authenticate A and B, 
respectively, since (by assumption) secrets Sa and Sb are shared only between 
the server and the respective agents. To check if the protocol accomplishes the 
authentication goal of A and B to S, we translate this in a formula that states 
that if S received a message M apparently from A (resp. B), then it was really 
sent by A (B). Server S authenticates A after receiving the first message, so at 
that point we set our formula: F$ — Be : e — {A : A, S, B,{ Ta, Sa, -Rijp^s) 1 ^)- 
Similarly, S authenticates B after the third message: i*V = Be : e = (B : 
B,S,A,{T B ,S B ,R2} P k(s) >S). 
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We performed verification with some test scenarios and did not find any trace 
that violates the above security requirements. Thus, we can regard the protocol 
to be secure for the system scenarios we tested; of course, bigger scenarios can 
be tested to increase confidence about the protocol security. 

4.5 Mutual authentication 

Even though Tatcbayashi and Matsuzaki do not state the mutual authentication 
of A and B, it is interesting to consider this case (Lowe and Roscoe [5] also 
discuss this.) We can translate this requirement by redefining two formulae, 
namely F3 and F 2 . We define F3 to express the local security property of A to 
B and F 2 expressing the authentication of B to A: 

• M authenticity of A to B: F 3 = 3e : e = {A : A, S, B, {T Al Sa, Ri} P k(s) > 
S); 

• M authenticity of B to A: F 2 = 3e : e = (B : B, S, A, {T B , S B , i?2} P fc(s) > 
S). 

Proceeding with verification, we found traces that violate F2 and F3. The 
attack trace for F3 is straightforward, consisting in only one message, sent from 
e(s) to b: s, b, a. But this is sufficient to violate formula F 3 , since when b receives 
s, b, a she wants to check if a sent a, s, 6, {t a , s a , ri} pk ^, which she did not (this 
attack is similar to attack 7.1 in 9 .) 

4.6 Novel authentication attacks 

In Table |3 we report two attacks that violate F 2 . 



Table 2: B to A authentication attacks 



aA. 


a — > 


s(s) 


a, s,b, {<Q,s a ,ri} pfe ( s ) 


a.l.a— > e(s) : a, s, b, {t a , s a , n} P fe(«) 


a.2. 


e(s) 


-> b 


s, 6, e 


p.l.e — > s : e,s,a,{te,s e ,rei} pk ( s ) 


a. 3. 


b^ 


e(s) 


b,s,e,{tb,s b ,r 2 }pk(s) 


(3.2. s — > e(a) : s,a,e 


13.1. 


e(a) 




a, s,b, {i a , s Q , ri} P fe( s ) 


/3.3.s(a) — ► s : a,s,e,{t ai s a ,ri} pk ( s ) 


(3.2. 




e(b) 


s, b, a 


(3A.s — y e : s,e,a,v(rei,ri) 


(3.3. 


s(b) 


— y s 


b,s,a,{tb, s b ,r 2 } p k(s) 


aA.e(s) —y a : s,a,b,v(ri,rei) 


(3A. 




e(a) 


s, a, 6, v(n, r%) 




aA. 


e(s) 


— * a 


s,a,b,v(n, r%) 





The attack of Table (left side) is successful since the intruder can manip- 
ulate the first three non-encrypted fields. Notice how F 2 is violated: when a 
receives message a. 4, b never sent message b, s, a, {fe, s&, J^jp^s). The attack 
reported in Table |21 (right side) is stronger, since the principal b is not alive in 
the run of a. 

We believe these attacks over this modified version of the TMN protocol 
have never been reported before in the literature. 
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5 Related Work 



In this section we discuss some related work. In ^B], Roscoe identifies two ways 
of specifying protocol security goals: firstly, using extensional specifications, 
and secondly using intensional specifications. An extensional specification 
describes the intended service provided by the protocol in terms of behavioural 
equivalence [HIE El- O n the other hand, an intensional specification describes 
the underlying mechanism of a procotol, in terms of states or events [21 12] Ht>l 

GHEES!!?]. 

The approach presented in this paper belongs to the spectrum of intensional 
specifications, and is related to ^3^5]. In J^j, a requirement specification lan- 
guage is proposed. This language is useful for specifying sets of requirements for 
classes of protocol; the requirements can be mapped onto a particular protocol 
instance, which can be later verified using their tool, called NRL Protocol An- 
alyzer. This approach has been subsequently used to specify the GDOI secure 
multicast protocol [T2] . 

In Roscoe presents a method for describing the underlying mechanism 
of a protocol, using a CSP specification. The method consists of four steps: 
Firstly, one identifies an execution point of the protocol that should not be 
reached without a corresponding legitimate run having occurred. Secondly, one 
describes the possible sequences of messages that should have occurred before 
this execution point; thirdly, one creates a specification which groups all the 
CSP processes modelling the protocol participants (this step is similar to our 
scenario setting). Finally, one verifies the specification using FDR. This method 
has been also used by Lowe in [5]. 

The approaches just mentioned employ languages specifying security prop- 
erties in a global fashion, as opposed to our technique which deals with local 
security properties. 

In U, Cremers, Mauw and de Vink present another logic for specifying local 
security properties. Similarly to us, in the authors define the message au- 
thenticity property by referring to the variables occurring in the protocol role. 
In addition, in 0], it is defined a new kind of authentication, called synchoniza- 
tion, which is then compared with the Lowe's intensional specification. The logic 
presented in this paper cannot handle the specification of the synchronization 
authentication. In fact, we cannot handle the weaker notion of injective authen- 
tication, since we cannot match corresponding events in a trace. However, we 
believe we can extend our logic to support these properties. Briefly, this could 
be achieved by decorating the different runs with label identifiers and adding a 
primitive to reason about events that happenned before others in a trace. 

6 Conclusions and Future Work 

We have developed a trace logic for expressing local security properties. Using 
this trace logic, the protocol designer can specify precisely the (local) security 
properties a protocol should satisfy to accomplish the security goals for which 
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it has been designed. 

The main differences between our approach and the ones mentioned in Sec- 
tion [S] can be summarized as follows: 

1. Our trace logic formulae are local to the participants, in the sense that 
are dependent to the principal's point of view, instead of global to the 
protocol specification. This allow us to define properties more precisely, 
in the sense of what should hold for each principal at each execution step. 

Furthermore, our technique can be used to integrate the specification 
within the design of a cryptographic protocol. Methodologically, this al- 
lows for the integration of the verification phase within the design one, 
speeding up the feedback from the verification, and providing the basis 
for an integrated environment for protocol engineering. 

2. Without having to use temporal operators, the logic we presented can 
express classical security properties including freshness and authenticity 
of the exchanged values during a protocol run. 

3. Our logic is applied directly to the protocol messages. This allow us to 
reason about (local) security properties without having to use artificial 
event messages. 

As future work, we plan to apply the methodology to more complex case 
studies, such as multicast protocols e.g. LKH group communications protocol 
|2()| . We also plan to study how to compose local security specifications: we 
believe this is a very important advantage of our approach over the other global 
ones. 
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